Remarks/Arguments 

The rejections presented in the Office action dated March 30, 2010 (hereinafter 
Office Action), have been considered. Reconsideration of the pending claims and 
allowance of the application in view of the present response is respectfully requested. 

Applicant respectfully maintains the traversal of each of the § 103(a) rejections, 
each of which is based upon at least a combination of the teachings of SyncML with those 
of Hillyard because the asserted references alone, or in combination, do not teach or suggest 
each of the claimed limitations. For example, neither of the asserted references teaches or 
suggests initiating a second synchronization session in accordance with role information 
defined and stored based on a first synchronization session. The assertion that SyncML 
teaches synchronization and Hillyard teaches checking role information for establishing a 
communication session fails to correspond to the claimed limitations directed to using 
synchronization role information for initiating a subsequent synchronization session. 

SyncML admittedly does not teach definition, based on a first synchronization 
session, checking, and use of role information for initiating a second synchronization 
session between devices that may perform both synchronization client and synchronization 
server roles. This is because the SyncML client and SyncML server are clearly determined 
roles in the cited SyncML protocol. The roles have very specific fiinctions, for example, 
regarding the initialization procedure set forth in Section 4, and the roles cannot be mixed. 
As taught by SyncML, only the synchronization client can initiate a synchronization session 
by sending a client initialization package (package #1). While the synchronization server of 
SyncML may trigger a session by sending an alert (as pointed out in the May 2008 Office 
action response), "this does not remove the need for the initialization" (SyncML page 25, 
second sentence). Thus, SyncML's server cannot be interpreted as a SyncML client. 
SjmcML does not teach a device capable of fimctioning as both a synchronization client and 
synchronization server such that SyncML does not recognize or address the problem of 
selecting an appropriate role for establishing a synchronization session. Moreover, there is 
no indication that a device would be capable of selectively changing between these 
synchronization roles or performing the role the selection as claimed. 
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Since Hillyard is unrelated to synchronization, Hillyard also fails to teach or suggest 
storage/use of role information on a synchronization device (either synchronization server 
or a synchronization client) that is defined on the basis of a first synchronization session or 
initiating a second synchronization session fi-om a synchronization device in accordance 
with such role information. Thus, neither of the asserted references has at least been shown 
to teach checking stored role information for a synchronization device in response to a need 
for initiating a second synchronization session. 

In contrast, Hillyard is directed to establishing communication connections between 
peer devices. Because the cited features of Hillyard are short-range Bluetooth transmission 
features directed to establishing a wireless link, there has been no suggestion that such 
features would, or could, be applied in upper protocol layer procedures. Specifically, 
Hillyard is directed to link establishment (OSI layer two functions) and is unrelated to 
arranging consecutive sessions (OSI layer five, session layer). The difference is illustrated 
in the situation where a mobile station roams from one link to another but maintains the 
session. SyncML also fails to suggest applying Bluetooth procedures for determining 
whether a device should establish a wireless connection. Thus, neither of the asserted 
teachings suggests that the connection establishment teachings of Hillyard could be used to 
modify the synchronization teachings of SyncML by a skilled artisan. As neither of the 
asserted references teaches or suggests at least definition and use of synchronization role 
information, as claimed, any combination thereof must also fail to teach such limitations. 
Without correspondence to each of the claimed limitations, the § 103(a) rejections are 
improper. 

Further, neither of the asserted references teaches or suggests using the stored role 
information to selectively transmit at least a server message to initiate a second 
synchronization session based on the defined role information. The above amendments to 
the independent claims more clearly set forth that a device transmits a server message in 
response to synchronization server being defined in the role information as the role of the 
device. To avoid confusion with SyncML's server initialization package #2, the server 
message is characterized as an alert message {see e.g., paragraph [0033] of the instant 

12 

KOLS.061PA 
Response to 30.03.2010 OA 



Specification). While Chapter 4 of SyncML discloses sync initialization, there is no 
suggestion of selecting a synchronization message based on pre-stored role information, 
which is a result of a preceding synchronization session. Hillyard also fails to teach role 
selection between consecutive sessions. In contrast to transmitting a server message in 
response to detecting a server role, Hillyard teaches performing a radio page scan 
(paragraphs [0054]-[0055]). Without correspondence to each of the claimed limitations, the 
§ 103(a) rejection would be improper, and Applicant accordingly requests that the rejection 
be withdrawn. 

Again, no evidence has been presented to support the assertion that a skilled artisan 
would look to the Bluetooth role information of Hillyard to negotiate database 
synchronization in SyncML. First, Hillyard makes no mention of, and is unrelated to, 
synchronization. Second, the Bluetooth RP technology taught by Hillyard is not related to 
the lower-layer transport technology, such as HTTP, used in SyncML's synchronization of 
databases. A skilled artisan using common sense would not look to use Hillyard's 
Bluetooth role information to establish synchronization sessions. "Combining prior art 
references without evidence of such a suggestion, teaching, or motivation simply takes the 
inventor's disclosure as a blueprint for piecing together the prior art to defeat patentability— 
the essence of hindsight." In re Dembiczak, 175 F.3d 994, 999 (Fed. Cir. 1999). "Not only 
must the claimed invention as a whole be evaluated, but so also must the references as a 
whole, so that their teachings are applied in the context of their significance to a technician 
at the time—a technician without ova knowledge of the solution." Interconnect Planning 
Corp. V. Feil, 11 A F.2d 1 132, 1 143 (Fed. Cir. 1985). The assertion that Hillyard teaches 
communication between devices without needing to be pre-configured for certain roles fails 
to identify why a skilled artisan would modify the teachings of SyncML with such 
teachings. As explained previously, the devices of SyncML are already taught as being 
configured as either a server or a client. Contrary to the assertion at page eight of the Office 
Action, the devices of SyncML are not peers, they have specifically defined roles. 
Therefore, Applicant respectfully submits that the proffered motivation is a hindsight 
combination of prior art based on Applicant's teachings, and the requisite showing of 
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motivation to combine Hillyard with SyncML has not been met. Applicant accordingly 
requests that each of the § 103(a) rejections be withdrawn. 

Moreover, Applicant maintains that Hillyard, being directed to very different 
technology than SyncML, is nonanalogous art. Since Hillyard is in a field different than 
Applicant's endeavor, to be considered reasonably pertinent, Hillyard would need to address 
a problem addressed by the application at issue (MPEP § 2141 .01(a)). As acknowledged by 
the Office Action, Hillyard is directed to establishing a wireless connection between devices 
automatically without any pre-configuration as to client/server roles (paragraphs [0013] and 
[0014]). Hillyard uses role information to re-establish a broken connection but only for a 
limited time or number of attempts. After the predetermined time/attempts are over, the 
devices reset to not having role information (paragraph [0055]). In contrast, the application 
at issue recognizes that it is essential for synchronization to maintain the roles of the 
synchronizing devices from one synchronization session to another (paragraph [0005]). 
Since Hillyard addresses devices without any role information, Hillyard would not be 
pertinent to defining and maintaining role information, as claimed. Hillyard, directed to 
very different technology and addressing a problem not recognized by the application at 
issue, would not have logically commended itself to an inventor of the instant application. 
Thus, Hillyard is nonanalogous art and fails to support the § 103(a) rejections. 

Regarding the § 103(a) rejections of various dependent claims. Applicant fiirther 
maintains the traversals because the teachings of U.S. Publication No. 2005/0091413 to 

Walbeck et al; U.S. Patent No. 5,884,323 to Hawkins et al.; U.S. Publication No. 
2001/0056442 by Dresevic et al.; and U.S. Patent No. 6,272,545 to Flanagin et al. do not 
overcome the above-discussed deficiencies in the combination of SyncML and Hillyard. 
The Office action still has not shown that any of these additionally relied upon references 
overcome the above-discussed deficiencies. Therefore, Applicant maintains that none of 
the asserted references has been shown to at least teach limitations directed to the definition 
of role information based upon a synchronization session, as claimed, and any combination 
thereof must also fail to teach such limitations. Without correspondence to each of the 
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claimed limitations, the § 103(a) rejections are improper, and Applicant requests that the 
rejections be withdrawn. 

With particular respect to the rejection of dependent claims 2, 14, 21, and 24, 
Applicant traverses because none of the asserted references has been shown to teach a 
device that changes synchronization roles (from a client role to a server role) in response to 

an error message. The cited portions of Walbeck teach a server-capable node assuming the 
role of server when attempts at waking up a preferred server node fail. There is no 
changing of synchronization roles between two devices, as claimed. As SyncML teaches 
devices with static roles and Hillyard at least fails to teach establishing a server role in 
response to an error message, none of the references corresponds to the claimed limitations. 
Without correspondence to each of the claimed limitations, the § 103(a) rejection is 
improper, and Applicant accordingly requests that the rejection be withdrawn. 

With particular respect to the rejection of dependent claims 5 and 27, Applicant 
maintains that U.S. Patent No. 5,884,323 to Hawkins et al. (hereinafter "Hawkins") has not 
been shown to teach the asserted claim limitations. The Office action acknowledges that 

the combination of SyncML and Hillyard docs not show role information being application- 
specific so that separate role information is stored in the device for each application and/or 
application profile in the device. Thus, the Office action solely relies upon the teachings of 
Hawkins as corresponding to such limitations; however, contrary to the assertions in the 
Office action, Hawkins does not teach such limitations. Instead, the cited portion of 
Hawkins merely teaches that applications are synchronized one by one. The 
synchronization in Hawkins is initiated using a single synchronization command (Col. 2, 
lines 52-56) and the synchronization roles of the palmtop and personal computer systems do 
not change (Col. 3, lines 1-4). There is no suggestion that Hillyard's role information 
would be stored separately for each application or used for synchronization and no 
suggestion that Hawkins' synchronization information would include role information since 
the roles never change. Therefore, the asserted combination does not teach or suggest that 
separate synchronization role information is stored for each application and/or application 
profile. Without a presentation of correspondence to each of the claimed limitations, the 
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§ 103(a) rejection is improper, and Applicant accordingly requests that the rejection be 
withdrawn. 

It should be noted that Applicant does not acquiesce to the Examiner's statements or 
conclusions conceming what would have been obvious to one of ordinary skill in the art, 
obvious design choices, common knowledge at the time of Applicant's invention, officially 
noticed facts, and the like. Applicant reserves the right to address in detail the Examiner's 
characterizations, conclusions, and rejections in future prosecution. 

Authorization is given to charge Deposit Account No. 50-3581 (KOLS.061PA) any 
necessary fees for this filing. If the Examiner beheves it necessary or helpful, the 
undersigned attorney of record invites the Examiner to contact the undersigned attorney to 
discuss any issues related to this case. 

RespectfiiUy submitted, 

HOLLINGSWORTH & FUNK, LLC 

8500 Normandale Lake Blvd., Suite 320 
Minneapolis, MN 55437 
952.854.2700 

Date: September 30, 2010 By: /Erin Nichols Matkaiti/ 

Erin Nichols Matkaiti 
Reg. No. 57,125 
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